40.5 KB · ⇊ 12 parts · ⤓ Micron 40.5 KB · ⤓ HTML 69.6 KB

top

mwawX.509 è uno standard proposto dall'mwbaUnione internazionale delle telecomunicazioni (ITU-T), usato per definire il formato dei mwbqcertificati a chiave pubblica (PKC) e delle mwbgautorità di certificazione (CA). I certificati vengono utilizzati per la validazione dell'identità e la trasmissione di dati criptati che solo il possessore (persona, organizzazione o applicazione) di uno specifico certificato è in grado di decifrare e leggere. Questi vengono rilasciati dalle mwbwCertificate authority (CA), un soggetto terzo fidato che assicura la corrispondenza di una mwcachiave pubblica a una determinata identità. Uno degli usi più diffusi di X.509 è nell'ambito mwcqinternet, il certificato mwcgSSL/TLS viene usato nell'omonimo mwcwprotocollo per mwdacriptare le comunicazioni tra un mwdqmwdgsito web e il nostro mwdwmweabrowser.

Lo standard inoltre definisce sotto diversi aspetti l'utilizzo dei certificati nelle mweginfrastrutture a chiave pubblica (PKI) e nei Privilege Management Infrastructure (PMI). Oltre al certificato a chiave pubblica e ai certificati di attributi vengono descritti anche i seguenti mwfatipi di dato: mwfqcertificate revocation list (CRL) e attribute certificate revocation list (ACRL).cite-ref-1[1]

Le mwgwcertificate revocation list (CRL) contengono la lista dei certificati che sono stati revocati dall'autorità rilasciante. Le CRL vengono consultate per assicurarsi la validità e affidabilità dei certificati che si stanno per utilizzare. Operazione svolta dal mwhamwhqbrowser ogni volta che ci si collega a un sito tramite mwhgSSL/TLS.

• Storia ed utilizzo

• Certificati

• Struttura di un certificato

• Estensioni tipiche dei file con certificati X.509

• Modalità di richiesta di un certificato

• Modalità di revoca di un certificato

• Catena di certificati

• Esempio di cross-certificate

• Sicurezza

• Gli anelli deboli nell'architettura dello standard

• Debolezze nella crittografia

• Certification Authority

• Protocolli che supportano i Certificati X.509

• Note

• Bibliografia

• Collegamenti esterni

L'mwigITU-T X.509 venne presentato per la prima volta nel mwiw1988 come parte dello standard mwjaX.500, insieme di raccomandazioni per un mwjqservizio di directory. Il formato dei certificati definito nel 1988 costituisce la versione uno(v1). Questo presupponeva uno stretto sistema di gerarchie di mwjgcertificate authority (CA) per garantire la legittimità di un certificato. In contrasto con il modello della mwjwrete di fiducia (mwkaweb of trust), utilizzato da mwkqPGP, dove chiunque, non solo i CA, può firmare e quindi attestare (certificare) la corrispondenza tra una chiave pubblica e il soggetto a cui essa appartiene.

Lo standard fu rivisitato nel 1993 con l'aggiunta del supporto di due nuovi attributi nel certificato, questa estensione costituisce la versione due (v2). Nello stesso anno con l'Internet Privacy Enhanced Mail (PEM) mwla[rfc-1422] veniva proposta un'mwlqinfrastruttura a chiave pubblica basata su X.509 versione uno(v1). L'esperienza fin qui acquisita fece emergere l'esigenza di un'ulteriore estensione, per rendere più dettagliati i certificati e favorirne l'interoperabilità sotto sistemi con profili diversi, come Internet. Nel 1996 fu quindi completata la versione tre (v3), dalla collaborazione d'mwlgISO/IEC, ITU-T, e mwlwANSI X9. La versione tre(v3) di X.509 permette una maggiore flessibilità nelle strutture di creazione dei certificati X.509, con possibilità di usare topologie di PKI in stile mwmamesh o bridge [rfc-4158], anche in una rete di fiducia mwmqpeer-to-peer come quella di mwmgOpen-PGP, raramente però è mwmwimplementata in questo modo. Questo aiutò a superare la rigida struttura gerarchica dei PKI.

Il sistema X.500 non è mai stato totalmente completato, e l'mwnqIETF e i mwngpublic-key infrastructure working group (PKIX) hanno adattato lo standard con una struttura più flessibile adatta a Internet. Infatti il termine mwnwcertificato X.509 si riferisce generalmente al profilo dei certificati e delle liste di revoca dei certificati (CRL, da Certificate Revocation List) dell'IETF basato su standard X.509 v3, come descritto nella mwoaRFC 5280.

Nel sistema X.509, una Certification Authority (CA) rilascia un certificato che accoppia una chiave pubblica a un nome univoco, oppure a un'entità come potrebbe essere un mwowindirizzo e-mail o un record mwpaDNS. L'autenticità di un certificato e dell'autorità di certificazione dipendono dal mwpqroot certificate. I mwpwroot certificate sono implicitamente fidati. Uno degli esempi di software distribuiti con mwqaroot certificate preinstallati sono i mwqqmwqgbrowser, rendendo possibile il funzionamento dei certificati mwqwSSL/TLS.cite-ref-0-2-0[2]

La versione tre (v3) dei certificati digitali X.509 ha tre voci principali: il certificato, l'identificativo dell'algoritmo di firma del certificato e la firma del certificato. Il certificato viene descritto attraverso una serie di attributi come la versione, l'ID dell'algoritmo, il numero seriale, l'emittente, il richiedente, la validità, informazioni sulla chiave pubblica del richiedente, estensioni e altre voci facoltative. Le informazioni sulla chiave pubblica del richiedente sono poi ulteriormente dettagliate con l'algoritmo utilizzato e la chiave pubblica stessa, mentre la validità viene indicata tramite la data d'inizio e quella di fine, che eventualmente determina il periodo di vita del certificato.

I codici identificativi univoci dell'emettitore e del richiedente sono stati introdotti nella versione due(v2), per poter permettere il loro riutilizzo in altri certificati. Per esempio se una Certification Authority (CA) fallisce e non è più autorizzata ad esercitare. In seguito un'altra CA con lo stesso nome, potrebbe registrarsi nella lista pubblica delle CA, anche se non ha nessuna relazione con la prima CA. Tuttavia la mwtwIETF raccomanda di non riutilizzare lo stesso nome. Perciò la versione due(v2) non ha avuto un ampio utilizzo in mwuaInternet.

Le estensioni sono state introdotte nella versione tre (v3). Una CA può usare le estensioni solo per certificati che hanno uno specifico uso, come la firma di oggetti digitali. Ogni estensione del certificato ha un proprio identificativo, espresso come mwugobject identifier (OID), un insieme di valori che possono essere critici o non critici. Se analizzando un certificato un sistema incontra un'estensione critica che non riconosce, il certificato viene rigettato. Un'estensione non critica può essere ignorata se non riconosciuta, ma altrimenti deve essere processata. L'mwvaRFC 5280 definisce, nella sezione 4.2cite-ref-tools-ietf-org-3-0[3], delle estensioni in uso nelle Internet PKI. Ulteriori estensioni possono essere utilizzate, ma si deve fare attenzione nell'includere estensioni critiche, poiché potrebbero compromettere l'interoperabilità del certificato.

In tutte le versioni, il numero seriale deve essere univoco per ogni certificato emesso da una specifica Certification Authority(CA).

Estensioni comuni per i file contenenti i certificati X.509:

• mwxg.pem - Privacy-Enhanced Mail, è un certificato codificato con mwyaBase64, racchiuso tra "-----BEGIN CERTIFICATE-----" e "-----END CERTIFICATE-----";

• mwyg.cer, mwyw.crt, mwza.der - certificato codificato con DER, a volte sequenze di certificati;

• mwzw.p7b, mwaa.p7c – struttura SignedData mwaqPKCS#7 senza dati, solo il/i certificato/i o la/le CRL (Certificate revocation list);

• mwaw.pfx, mwba.P12 - mwbqPKCS#12, può contenere certificati e chiavi pubbliche e private (protette da mwbgpassword);

PKCS #7 è uno standard per la firma o la crittazione (viene chiamata "imbustamento", "incapsulazione", "mwcaenveloping" in inglese) dei dati. Poiché è necessario un certificato per verificare i dati firmati, è possibile includerli in una struttura SignedData. Un file mwcq.p7c non è altro che una struttura SignedData "degenere" (senza dati firmati).

PKCS #12 è nato dallo standard PFX (Personal inFormation eXchange) ed è usato per scambiarsi oggetti pubblici e privati all'interno dello stesso file.

Un file mwda.pem può essere utilizzato oltre che per i certificati anche per le chiavi private, racchiusi tra le apposite linee BEGIN/END.

Una persona/entità può richiedere di certificare la propria chiave pubblica inviando un mwdwCertificate Signing Request (CSR) a una Certification Authority (CA). Per prima cosa si genera una coppia di chiavi (privata/pubblica). La chiave privata viene tenuta segreta e viene utilizzata per firmare il CSR. La richiesta contiene tutte le informazioni necessarie per validare l'identità del richiedente, oltre alla chiave pubblica. In seguito alle verifiche il certificato viene firmato digitalmente dalla CA per evitare ulteriori modifiche. A questo punto la CA pubblica il certificato affinché altri lo possano trovare.

Esistono differenti tipi di entità definite in X.509:

• Certification Authority (CA): emette certificati, genera CRL, genera la coppia chiave Pb e Pr, conferma che ogni utente che richiede l'emissione del proprio certificato è in possesso della corrispondente chiave privata, verifica l'unicità della chiave Pb.

• Local Registration Authorities: alcune CA richiedono la presenza fisica dell'utente finale e quindi una LRA gioca il ruolo di intermediario, che risolve questo problema.

• Root Authority: è l'autorità che è in carica per approvare la politica di certificazione globale. Usata solitamente per certificare altre CA, non utenti.

• Policy certification Authority: permette di creare, per alcuni gruppi di utenti, estensioni di politiche di certificazione stabilite originalmente.

• L'utente finale: genera e verifica documenti firmati

Lo standard X.509 definisce il formato e la semantica delle mwgqcertificate revocation list (CRL), liste di revoca di certificati, per le PKI. Ogni oggetto della mwggCertificate Revocation List include il numero seriale del certificato revocato e la data di revoca. Anche i file delle CRL sono firmate dalla mwgwCertificate Authority per prevenire manomissioni. Possono essere aggiunte informazioni opzionali come un limite temporale se la revoca si applica solo per un periodo di tempo o la ragione della revoca.

Il problema con le CRL, come con tutte le mwhqmwhgblacklist, è la difficoltà di manutenerle e sono un modo inefficiente di distribuire informazioni critiche in mwhwmwiasistema real-time. Tutto dipende dalla frequenza di aggiornamento delle CRL, anche se ad esempio sono aggiornate ogni ora, un certificato revocato potrebbe ancora essere accettato. Inoltre se una CRL non è disponibile, qualsiasi servizio si basi su questa non è utilizzabile.

Il protocollo mwigOnline Certificate Status Protocol (OCSP) è un'alternativa alle CRL, questo manda il certificato alle CA per essere verificato direttamente da loro, modalità utilizzata dai mwiwbrowser. Utilizzando meno traffico dati per effettuare la verifica.cite-ref-4[4]

Un servizio che utilizza i certificati X.509, richiede la conoscenza di una chiave pubblica, prima di usare il certificato che la contiene questo deve essere validato. Se il servizio non ha già una copia valida della chiave pubblica del CA che ha firmato il certificato, il nome della CA, e le relative informazioni (come il periodo di validità), si ha bisogno di ulteriori certificati per ottenere quella chiave pubblica. In generale, si ha bisogno di una lista di certificati, incluso il certificato del proprietario della chiave pubblica (mwkgend-entity certificate) firmato da una CA, seguito da uno o più certificati di CA firmati da altre CA. Queste mwkwcatene di certificati (chiamate anche mwlacertification pathscite-ref-tools-ietf-org-3-1[3]) sono necessarie poiché i software di solito sono inizializzati con un limitato numero di chiavi pubbliche di CA verificate.

Una mwmgcatena di certificati ha le seguenti proprietà:

1. L'entità emittente di ogni certificato deve combaciare con il richiedente del certificato successivo nella lista. Ad eccezione dell'ultimo, di solito auto firmato.

2. Ogni certificato deve essere firmato dalla chiave privata corrispondente al successivo certificato nella catena. Perciò la firma di un certificato può essere verificata utilizzando la chiave pubblica contenuta nel certificato successivo.

3. L'ultimo certifica nella lista è il mwnwroot certificate, chiamato anche mwoatrust anchor: certificato intrinsecamente fidato.

Possiamo distinguere tra un certificato emesso per le CA e quelli emessi per gli mwowend-entity (per esempio utenti, dispositivi, mwpaserver Web, processi) grazie all'estensione mwpqBasic Constraintscite-ref-5[5]. Un certificato emesso per una CA sono chiamati mwqgcross-certificate. I mwqwcross-certificate vengono utilizzati sia in un modello con una struttura gerarchica, dove una CA più autorevole (cross-)certifica una CA subordinata, sia in un modello distribuito, dove diverse CA possono emettere certificati una per l'altracite-ref-6[6].

Tutti i certificati nella catena devono essere controllati. In generale, il processamento di una catena di certificati avviene in due fasi:

1. La costruzione di una o più eventuali catene di validazione di certificati. Eventuali poiché alcune di queste potrebbero non essere validi per diversi motivi, come la lunghezza della catena o per restrizioni/vincoli riscontrati.

2. Validazione della catena, che include la verifica che ogni certificato nella catena sia ancora nel periodo di validità, non sia stato revocato, sia integro, e inoltre che ogni estensione critica sia rispettata.

Esaminando come una catena di certificati viene costruita e validata, si nota che un certificato può fare parte di diverse catene di certificati, al più tutte valide. Questo grazie ai mwuqcross-certificate. Si possono infatti generare più certificati per una CA con lo stesso soggetto e chiave pubblica, ma essere firmati con diverse chiavi private, da diverse CA. Quindi, nonostante un singolo certificato X.509 possa avere un solo ente emittente e una sola firma, questo può essere collegato a più di un certificato in maniera valida. Questo è un aspetto cruciale per (cross-)certificare molteplici PKI e diverse applicazioni.

Nel diagramma, ogni rettangolo rappresenta un certificato, con il soggetto in grassetto. A → B significa "A è stato firmato da B" (più precisamente, "A è stato firmato dalla chiave privata corrispondente alla chiave pubblica nel certificato B"). I certificati con lo stesso colore (ad eccezione di quelli trasparenti) contengono la stessa chiave pubblica.

Per assicurarsi ad esempio che gli mwvqend-entity certificate in PKI.2, come il cert.2.2, siano verificabili tramite PKI.1, la CA.1 genera un certificato contenente la chiave pubblica di CA.2, in questo caso cert.2.1. Adesso sia cert.2 sia cert.2.1 in verde hanno lo stesso soggetto e chiave pubblica. In questo modo ci sono due catene valide per cert.2.2 (User.2):

• cert.2.2 → cert.2

• cert.2.2 → cert.2.1 → cert.1

In maniera simili, la CA.2 può generare un certificato che contiene la chiave pubblica di CA.1 (cert.1.1), in modo che i certificati all'interno di PKI.1 siano riconosciuti da PKI.2.

Ci sono numerose pubblicazioni sui problemi delle PKI da parte di mwxaBruce Schneier, mwxqPeter Gutmann e altri esperti di sicurezza.cite-ref-1-7-0[7]cite-ref-8[8]cite-ref-2-9-0[9]

• Le CRL sono delle mw1qblacklist per i certificati non più validi. Una delle cause più comuni per la revoca di un certificato è la compromissione della sua chiave privata. Il problema è nella manutenzione della lista e nella sua distribuzione non efficiente. Quindi per un sistema un certificato potrebbe risultare ancora valido, anche se formalmente è stato revocato. Inoltre le CRL possono raggiungere dimensioni notevoli, per questo nel percorso di verifica dello stato di un certificato di solito intervengono dei sistemi di mw1wmw2acache delle liste, per evitare di doverla mw2qscaricare ad ogni richiesta. Questo pone anche il problema dell'aggiornamento della mw2gcache. Se le CRL non sono disponibili, ogni servizio legato ai certificati risulta non utilizzabile, il che può creare un mw2wdenial of service, perdendo quindi la capacità di operare mw3aoffline.

• Il mw3wOnline Certificate Status Protocol (OCSP) è protocollo utilizzato dai mw4amw4qbrowser per la verifica dei certificati mw4gSSL/TLS. È una versione migliorata delle CRL. Anche questo, come le CRL, può presentare problemi di mw4wlatenza e non disponibilità dei mw5aserver delle CA. In generale per poter continuare ad utilizzare un determinato servizio si tende ad ignorare il problema di risposta OCSP non ricevuta o i messaggi di errore, comportamento chiamato mw5qsoft-fail. Adam Langleycite-ref-10[10] disse che la verifica mw6gsoft-fail delle CRL è come la cintura di sicurezza che funziona ad eccezione di quando dovrebbe:

«So soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it's worthless because it only works when you don't need it.»

(Adam Langley, Revocation checking and Chrome's CRL)

• Un'altra problematica deriva dal fatto che diversi mw7gbrowser usano diverse modalità di verifica delle CRL. A meno che non venga utilizzato un Extended Validation Certificate, alcuni mw8abrowser controllano solo la validità del certificato del mw8qserver e non dell'intera catena di certificati. Inoltre permettono che la sessione continui senza alcun messaggio di errore.

• Un'alternativa all'OCSP è l'OCSP Stapling. Questo permette di spostare il processo d'interrogazione delle CRL dal mw9abrowser al mw9qHTTPS mw9gServer. Il mw9wserver perciò può periodicamente verificare lo stato del suo certificato, e informare il mw-amw-qclient. In questo modo si elimina la dipendenza tra il mw-gbrowser e le CA, con conseguente diminuzione del tempo d'interrogazione, maggiore mw-wprivacy per chi usa un servizio e minore carico sui server delle CA. Però il mw-amw-qbrowser non sa quando aspettarsi una risposta OCSP mw-gStapling poiché questa è opzionale. Quindi un certificato revocato usato senza mw-wOCSP Stapling ricade nelle stesse problematiche del OCSP.cite-ref-11[11] Anche se l'OCSP mwaqqStapling presenta molteplici vantaggi rispetto al OCSP, la sua adozione non è molto diffusa ed è scarsamente supportato dai mwaqubrowser e mwaqyserver.

• La revoca dei mwaqgroot certificate è una questione che non viene affrontata. Se la lista dei mwaqkroot certificate viene compromessa con chiavi pubbliche mwaqoroot non legittime, queste possono essere usate per creare certificati validi. Non basta quindi tenere le chiavi pubbliche mwaqsroot in un certificato mwaqwroot, poiché questo è auto firmato e non offre nessuna sicurezza in più.cite-ref-1-7-1[7]

• Le PKI nello stile X.509 sono una rubrica di nomi, in base ai quali viene reperita la chiave pubblica dell'entità con cui si vuole comunicare. Ma ci possono essere delle ambiguità nei nomi, o molteplici entità con lo stesso nome, quindi per creare un identificativo univoco vengono aggiunte altre informazioni, per rendere distinguibile un'entità all'interno della stessa CA.cite-ref-2-9-1[9]

La sicurezza di una mwargfirma digitale si basa su una mwarkfunzione crittografica di hash. Nel momento in cui una PKI autorizza l'uso di una mwarofunzione di hash non più sicura, questa può essere sfruttata per compromettere i certificati. Più precisamente, se qualcuno riesce a produrre una collisione per una funzione di hash, dove il hash di un certificato è identico a un altro hash, di un certificato il cui contenuto è stato creato da un mwarscracker. In seguito il mwar0cracker aggiunge la firma fornita dalla CA al proprio certificato, che risulta legittimamente firmato da un CA. Essendo il contenuto scelto dal mwar8mwasacracker, ad esempio questo può estendere la validità di mwasemwasihostname oltre il suo termine oppure può inserire il campo mwasmCA: true abilitandosi all'emissione di altri certificati.

• Nel 2005, mwasyArjen Lenstra e Benne de Weger dimostrarono la possibilità di creare due certificati X.509 con la stessa firma ma che differiscono solamente per la chiave pubblica, grazie a un attacco a collisione sulla funzione di hash mwaskMD5.cite-ref-12[12]

• Nel 2008, Alexander Sotirov e Marc Stevens presentarono al Chaos Communication Congress un modo pratico per la creazione di una mwataCertificate Authority fittizia, accettata da tutti i più comuni mwatebrowser, sfruttando il fatto che RapidSSL emetteva ancora certificati basati su mwatiMD5.cite-ref-13[13]

• Nel 2009 all'Eurocrypt Conference, un ricercatore australiano dell'mwatkUniversità di Macquarie presentò un metodo per l'incremento della possibilità di collisioni nella funzione di hash SHA-1.cite-ref-14[14]

• Nel 2017 un gruppo di ricercatori produsse una collisione nella funzione SHA-1, dimostrandone la debolezza.cite-ref-15[15]

Lo sfruttamento delle collisioni nelle mwauufunzioni di hash per manomettere i certificati X.509 implicano che il mwauymwauccracker conosca a priori il contenuto del certificato firmato dalla CA. Questa possibilità può essere ridotta dalle CA stesse, introducendo un componente mwaugaleatorio nel certificato, tipicamente il numero seriale.

La CA/Browser Forum richiede l'utilizzo del numero seriale dal 2011, nelle sue mwausBaseline Requirements.cite-ref-16[16]

Dal 2016 inoltre le mwaveBaseline Requirements proibiscono l'emissione di certificati che fanno uso dell'algoritmo di hash mwaviSHA‐1. L'anno successivo i mwavmbrowser come mwavqChrome, mwavuFirefox, mwavyEdge e mwavcSafari non accettavano più certificati firmati con mwavgSHA-1.cite-ref-17[17]cite-ref-18[18]cite-ref-19[19]cite-ref-20[20] Ci sono però numerosi mwawksoftware non-mwawobrowser che accettano ancora i certificati SHA-1.cite-ref-21[21]

• mwaxiLet's Encrypt, una certification authority che rilascia certificati a titolo gratuito. mwaxmLet's Encrypt, su letsencrypt.org.

• mwaxuActalis S.p.A., una certification authority italiana che rilascia certificati X.509 a titolo gratuito, con validità annuale. mwaxyActalis S.p.A., su actalis.it.

• mwaxgComodo, una certification authority statunitense che rilascia certificati X.509 a titolo gratuito, con validità annuale. mwaxkComodo Group, su comodo.com. URL consultato il 9 aprile 2018 (archiviato dall'url originale il 6 aprile 2018).

• mwaxsCACert, su cacert.org.

• mwax0StartSSL, su startssl.com.

• mwax8Thawte, su thawte.com.

• mwayeVeriSign, su verisign.com.

• mwayuTransport Layer Security (SSL/TLS)

• mwaycIPSec

• mwaykSecure Multipurpose Internet Mail Extensions (S/MIME)

• mwaysSmartcard

• mway0SSH

• mway8HTTPS

• mwazeLDAPv3

• mwazmEAP

cite-note-11. ↑ mwazo(mwazsmwazwEN) mwaz0mwaz4ITU-T Recommendation database, su mwaz8ITU. mwaaaURL consultato il 3 gennaio 2019.

cite-note-0-22. ↑ mwaaqmwaaumwaayX.509, su mwaactech-faq.com. mwaagURL consultato il 25 gennaio 2019.

cite-note-tools-ietf-org-33. ↑ mwaa4(mwaa8mwabaEN) Dave Cooper, mwabemwabiInternet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, su mwabmtools.ietf.org. mwabqURL consultato il 26 gennaio 2019.

cite-note-44. ↑ mwabg(mwabkmwaboEN) mwabsmwabwWhat is Certificate Revocation List (CRL)? - Definition from WhatIs.com, su mwab0SearchSecurity. mwab4URL consultato il 26 gennaio 2019.

cite-note-55. ↑ mwaci(mwacmmwacqEN) Dave Cooper, mwacumwacyInternet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, su mwacctools.ietf.org. mwacgURL consultato il 26 gennaio 2019.

cite-note-66. ↑ mwacwmwac0mwac4Understanding Certification Path Construction (mwac8mwadaPDF), su mwadeoasis-pki.org. mwadiURL consultato il 23 gennaio 2019 mwadm(archiviato dall'mwadqurl originale il 4 febbraio 2019).

cite-note-1-77. ↑ mwadomwadsmwadwTen Risks of PKI (mwad0mwad4PDF), su mwad8schneier.com.

cite-note-88. ↑ mwaemmwaeqmwaeuPKI: It’s Not Dead, Just Restin (mwaeymwaecPDF), su mwaegcs.auckland.ac.nz.

cite-note-2-99. ↑ mwae4mwae8mwafaEverything you Never Wanted to Know about PKI but were Forced to Find Out (mwafemwafiPDF), su mwafmcs.auckland.ac.nz.

cite-note-1010. ↑ mwafcmwafgmwafkImperialViolet - Revocation checking and Chrome's CRL, su mwafoimperialviolet.org. mwafsURL consultato il 27 gennaio 2019.

cite-note-1111. ↑ mwaf8Alexey Samoshkin, mwagamwageSSL certificate revocation and how it is broken in practice, su mwagiMedium, 4 gennaio 2018. mwagmURL consultato il 27 gennaio 2019.

cite-note-1212. ↑ mwagcmwaggmwagkOn the possibility of constructing meaningful hash collisions for public keys (mwagomwagsPDF), su mwagwwin.tue.nl.

cite-note-1313. ↑ mwahamwahemwahiMD5 considered harmful today, su mwahmwin.tue.nl. mwahqURL consultato il 27 gennaio 2019.

cite-note-1414. ↑ mwahgmwahkmwahoSHA-1 collisions now 2^52 (mwahsmwahwPDF), su mwah0eurocrypt2009rump.cr.yp.to.

cite-note-1515. ↑ mwaiemwaiimwaimThe first collision for full SHA-1 (mwaiqmwaiuPDF), su mwaiyshattered.io. mwaicURL consultato il 27 gennaio 2019 mwaig(archiviato dall'mwaikurl originale il 15 maggio 2018).

cite-note-1616. ↑ mwai0mwai4mwai8Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (mwajamwajePDF), su mwajicabforum.org.

cite-note-1717. ↑ mwajy(mwajcmwajgEN) mwajkmwajoSHA-1 Certificates in Chrome, su mwajsGoogle Online Security Blog. mwajwURL consultato il 27 gennaio 2019 mwaj0(archiviato dall'mwaj4url originale il 2 marzo 2019).

cite-note-1818. ↑ mwaki(mwakmmwakqEN) mwakumwakyThe end of SHA-1 on the Public Web, su mwakcMozilla Security Blog. mwakgURL consultato il 27 gennaio 2019.

cite-note-1919. ↑ mwakw(mwak0mwak4EN) BetaFred, mwak8mwalaMicrosoft Security Advisory 4010323, su mwaledocs.microsoft.com. mwaliURL consultato il 27 gennaio 2019.

cite-note-2020. ↑ mwaly(mwalcmwalgEN) mwalkmwaloMove to SHA-256 signed certificates to avoid connection failures, su mwalsApple Support. mwalwURL consultato il 27 gennaio 2019.

cite-note-2121. ↑ mwama(mwamemwamiEN) mwammmwamqLesser HTTPS for non-browsers | daniel.haxx.se, su mwamudaniel.haxx.se. mwamyURL consultato il 27 gennaio 2019.

• mwamoArjen Lenstra, Xiaoyun Wang e Benne de Weger, Colliding X.509 Certificates, 1 March 2005, ePrint archive, mwam0.

• (EN) Sito ufficiale, su itu.int.

• mwanmhttps://web.archive.org/web/20061205051729/http://ietf.org/html.charters/pkix-charter.html

• mwanuInternet X.509 Public Key Infrastructure Certificate and CRL Profile (RFC 5280) (TXT), su ietf.org.

• Peter Gutmann's mwancX.509 Style Guide

• mwankhttp://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf mwanoArchiviato il 4 febbraio 2019 in Internet Archive.